How do you stop a running container?
You stop a running container using the docker stop command followed by the container ID or name, which sends a SIGTERM signal to allow graceful shutdown before forcibly stopping with SIGKILL after a timeout.
The docker stop command is the primary way to gracefully stop a running container. It sends a SIGTERM signal to the container's main process, allowing it time to clean up resources, save state, and shut down properly. If the container hasn't stopped after the configured grace period (default 10 seconds), Docker sends a SIGKILL signal to force termination. This approach balances clean shutdown with eventual termination, making it safer than abruptly killing containers.
After issuing docker stop, the container transitions from a running state to exited. You can verify this with docker ps -a. The container's filesystem and logs remain available unless you used --rm when starting it. The default 10-second timeout is configurable per container at runtime using the --stop-timeout flag, or globally by adjusting the Docker daemon's configuration.
For cases where a container is unresponsive to SIGTERM or you need immediate termination, docker kill sends a SIGKILL signal directly, bypassing the grace period. This should be a last resort, as it doesn't allow the application to perform cleanup tasks. You can also use docker kill --signal=SIGHUP to send custom signals for specific application behavior like log rotation or configuration reload.
- 1
docker stop: Sends SIGTERM, waits 10 seconds (by default), then SIGKILL if needed. Preferred for normal shutdown. - 2
docker kill: Sends SIGKILL immediately. Use for unresponsive containers or when immediate termination is required. - 3
docker kill --signal=SIGTERM: Same behavior asdocker stopbut without the automatic SIGKILL fallback. - 4
Ctrl+C in foreground terminal: Equivalent to
docker stopfor the container running in the foreground.
When stopping containers in production environments, ensure your application handles SIGTERM gracefully. Well-behaved containers should catch this signal, close database connections, flush logs, and complete any in-progress operations before exiting. Docker provides the --stop-signal flag to specify which signal to use, allowing you to customize shutdown behavior for applications that don't respond to SIGTERM.
Scenario Questions
- 1
You have a Docker container running a simple web server. How would you stop it from the command line, and what does Docker do during that process?
- 2
If you run
docker stopon a container that’s currently processing a request, what happens to that request and why?
- 1
During a deployment, you notice that
docker stopsometimes hangs and the container doesn’t exit. How would you troubleshoot and what alternatives could you use? - 2
Your CI pipeline uses
docker stopto clean up containers, but a flaky test sometimes leaves containers running. How would you modify the script to ensure containers are always terminated?
- 1
You’re building an internal platform that launches hundreds of containers per minute. What considerations would you make when choosing between
docker stopanddocker killfor graceful shutdown, especially under load? - 2
Explain how you would implement a timeout strategy for stopping containers to avoid resource leaks while ensuring in‑flight work can finish.
- 1
Your organization is migrating from a monolithic service to a microservice architecture orchestrated by Kubernetes, but some legacy components still use raw Docker commands. How would you design a strategy for handling graceful shutdowns across both environments to maintain reliability?
- 2
When designing a multi‑team container runtime abstraction, what policies would you enforce around stopping containers to balance safety, performance, and operational simplicity?
Follow-up Questions
- ❓What would you do if the container never exits after the timeout?
- ❓How can you change the default stop timeout for a specific container?
- ❓When might you prefer `docker kill` over `docker stop` in production?